讓我們開始今天的主題 – 如何使用新的 Karbon API 部署 Kubernetes。
Nutanix 官網上對 Karbon 的描述如下：
使用企業 Kubernetes 管理解決方案 Karbon 快速建立生產雲原生基礎架構的方式。
大大簡化了配置，操作和生命週期管理。
– https://www.nutanix.com/products/karbon
作為開發人員，這對我們意味著什麼？ Kubernetes 本身本身就是一個巨大的話題，因此，有關 Kubernetes 的詳細信息不在本文的討論範圍之內。 也就是說，Kubernetes（或K8s）對於新玩家來說可能是一個相當艱鉅的前景。 這可以包括諸如理解為什麼首先要存在 K8s，要求是什麼以及如何啟動和運行 K8s 集群之類的事情。 Karbon 大大簡化了可能相當複雜的過程，尤其是如果該過程是手動完成的。
就像決定將 Kubernetes 稱為 K8s 的開發人員一樣，我會很懶惰，並假設您具有腳本或第三方集成，需要以編程方式部署K8s 集群。 明確地說，我們正在部署 K8s 集群，但是我們將使用 Nutanix Karbon 來實現。 更輕鬆！
Nutanix Karbon API 是一個在2020年7月提供，相對較新的版本。對 Nutanix APIs 感興趣的人會在 API 參考頁上留意到一個新資源 – 這使您可以快速訪問 Karbon API 文檔。今天文章涵蓋的所有內容都可以在那裡以正式形式獲得，包括此文未提到的其他 API。
遍歷Karbon API公開的各種端點時，您會看到各種端點前綴：
就像先前所暗示的，一些可用的端點是通用（GA）並以/ karbon / v1開頭，而其他端點仍被視為 alpha 或 beta 並以/karbon/v1-beta.1或/ karbon / v1-alpha.1。 在生產環境中使用 alpha 或 beta API 端點之前，應採取適當的謹慎措施。
值得注意的是，我們今天將使用的主要 API 端點以/ karbon / v1 為前綴，並被視為 GA。 唯一的例外是，但我會在適當的時候提及它。
與所有 API 測試和開發一樣，我使用的是 Postman 集合來整理我的請求。 如果您是 Postman 的新手，請參考“這麼多變量！ 我如何使用Postman測試Nutanix API”。 它涵蓋了我如何使用 Postman 來完成我們今天要做的事情。
Here are the software versions I’m using on my development cluster:
Karbon確實有先決條件，所以這是我正在做的一些高級假設。 這些適用於在自己的環境中關注本文的任何人。
在創建新集群之前，讓我們快速看一下我們的環境中可能已經在運行哪些集群。
為此的請求URI如下（這是今天文章中的單個請求，可以通過beta端點進行訪問）：
Nutanix
https://[prism_central_ip_address]:9440/karbon/v1-beta.1/k8s/clusters
通過將此 GET 請求發送到 Prism Central，JSON 響應將包含有關由 Karbon 管理的現有 K8s 集群（如果有）的詳細信息。 在我的測試環境中運行時，此請求表明 Karbon 正在管理三個現有的 K8s 集群。 整個響應很長–請注意，以下屏幕截圖僅顯示響應中的第一個群集。
包含由Karbon管理的所有3個Kubernetes集群的JSON數組
如您在上面的屏幕快照中所見，我們現在具有有關可見集群的 etcd 配置，API 服務器的 IP 地址，主部署類型（單個主服務器）以及有關 worker 和 Kubernetes 版本的信息的詳細信息。
由於我們將使用 Karbon 和 Karbon API 部署 Kubernetes 集群，因此我們現在可以開始構建請求。 首先，這是我們將使用 Karbon 部署 K8s 集群的請求 URI：
https://[prism_central_ip_address]:9440/karbon/v1/k8s/clusters
這是一個 POST 請求，因此需要一個相應的 JSON 淨荷，該淨荷告訴 Karbon API 我們實際上想要做什麼。 作為一個小問題，讓我們看一下如果根本沒有任何 JSON 負載的情況下向該 URI 提交請求會發生什麼情況：
{
"code": 602,
"message": "body in body is required"
}
如您所見，我們很禮貌地告訴我們，缺少 JSON 正文，這是我們進一步進行之前所必需的。 在此過程中，如果您意外忽略了有效負載中的必填參數或字段，則會看到類似的消息。 不太相關，但是在談論 HTTP POST 請求時，我經常互換“有效載荷”和“正文”兩個詞。 在這些文章的上下文中，它們是同一回事。
如果您已經接觸過 Kubernetes，您會知道主節點配置可以是單主機或多主機。 這是一個過分的簡化，但是單主機基本上與 Nutanix Karbon 中的“開發”部署相匹配。 單主機開發集群將由以下組件組成：
1x大師
2x工人
1個etcd
請參閱 Kubernetes 組件以獲取有關各種 Kubernetes 組件的信息。
對於此初始部署，重要的是要注意此配置不被認為是高度可用的。 虛擬機中的任何一個組件都可能發生故障，從而導致群集不可用。
首先，讓我們看一下可用於部署由 Nutanix Karbon 管理的單主 Kubernetes 集群的 JSON 有效負載。
{
"cni_config": {
"flannel_config": {},
"pod_ipv4_cidr": "172.20.0.0/16",
"service_ipv4_cidr": "172.19.0.0/16"
},
"etcd_config": {
"node_pools": [
{
"ahv_config": {
"cpu": 1,
"disk_mib": 122880,
"memory_mib": 8192,
"network_uuid": "{{subnet_uuid}}",
"prism_element_cluster_uuid": "{{cluster_uuid}}"
},
"name": "dev_etcd_node_pool",
"node_os_version": "ntnx-0.6",
"num_instances": 1
}
]
},
"masters_config": {
"node_pools": [
{
"ahv_config": {
"cpu": 1,
"disk_mib": 122880,
"memory_mib": 8192,
"network_uuid": "{{subnet_uuid}}",
"prism_element_cluster_uuid": "{{cluster_uuid}}"
},
"name": "dev_master_node_pool",
"node_os_version": "ntnx-0.6",
"num_instances": 1
}
],
"single_master_config": {}
},
"metadata": {
"api_version": "v1.0.0"
},
"storage_class_config": {
"default_storage_class": true,
"name": "default-storageclass",
"reclaim_policy": "Delete",
"volumes_config": {
"file_system": "ext4",
"password": "{{pe_password}}",
"prism_element_cluster_uuid": "{{cluster_uuid}}",
"storage_container": "{{container_name}}",
"username": "{{username}}"
}
},
"workers_config": {
"node_pools": [
{
"ahv_config": {
"cpu": 1,
"disk_mib": 122880,
"memory_mib": 8192,
"network_uuid": "{{subnet_uuid}}",
"prism_element_cluster_uuid": "{{cluster_uuid}}"
},
"name": "dev_worker_node_pool",
"node_os_version": "ntnx-0.6",
"num_instances": 2
}
]
},
"name": "{{cluster_name}}",
"version": "1.16.10-0"
}
JSON有效負載中包含很多信息，因此讓我們檢查一下它的主要功能。
由{{cluster_name}}指示的群集名稱
組件（如前所述）
1x大師
2x工人
1個etcd
主節點，工作節點和etcd節點均配置如下：
1個vCPU
122880 MiB存儲
8GiB虛擬RAM
已連接到同一虛擬機網絡，以{{subnet_uuid}}表示
部署到由{{cluster_uuid}}指示的同一Prism Element群集
Kubernetes版本1.16.10-0
Nutanix主機操作系統版本ntnx-0.6
CIDR範圍
服務：172.19.0.0/16
吊艙：172.20.0.0/16
名為default-storageclass的存儲類
ext4文件系統
回收策略設置為“刪除”
{{container_name}}指示的存儲容器
Karbon API版本1.0.0
值得注意的是，每個節點類型的配置詳細信息（例如，master / worker / etcd節點的ahv_config）當然可以有所不同。我對所有設備都使用相同的配置，因此有效負載要簡單一些。
使用 Karbon UI 進行 Kubernetes 集群部署的用戶會注意到，每個參數都與您在 Karbon UI 中看到的1：1匹配。換句話說，在使用 Karbon UI 時選擇的選項也都已在 JSON 有效負載中指定。
將請求發送到 Prism Central 會返回類似於以下所示的 JSON 響應–請注意，此響應顯示在 require 變量已替換為實際集群名稱等之後的值：
{
"cluster_name": "single01",
"cluster_uuid": "30efbfd8-5544-4a58-53c4-2545658cc981",
"task_uuid": "21da123c-8911-41e8-acef-7653cbdc2aaa"
}
根據JSON有效負載的集群名稱清晰可見，我們的新集群的UUID以及為處理該流程而創建的任務的UUID也清晰可見。 就本文而言，我們可以忽略task_uuid和cluster_uuid-Karbon API可用於獲取有關當前情況的信息。 我們將盡快完成。
多主 Kubernetes 集群的 JSON 有效負載略有不同。 除了在單個主有效負載中指定的信息之外，我們還可以指定一些其他屬性。 在生產環境中，您更可能會使用與此類似的東西，並調整各種參數以提供高度可用的配置。
主節點群集的外部 IPv4 地址（如果正在使用主動/被動配置）（此有效負載將對此進行演示）。
主節點實例數。 在單主機配置中將其設置為1，但在此處將其設置為2。
請注意，single_master_config 對像已從有效負載中刪除-不適用於多主設備配置。
完整的 JSON 有效負載如下所示：
{
"cni_config": {
"flannel_config": {},
"pod_ipv4_cidr": "172.20.0.0/16",
"service_ipv4_cidr": "172.19.0.0/16"
},
"etcd_config": {
"node_pools": [
{
"ahv_config": {
"cpu": 1,
"disk_mib": 122880,
"memory_mib": 8192,
"network_uuid": "{{subnet_uuid}}",
"prism_element_cluster_uuid": "{{cluster_uuid}}"
},
"name": "dev_etcd_node_pool",
"node_os_version": "ntnx-0.6",
"num_instances": 1
}
]
},
"masters_config": {
"active_passive_config": {
"external_ipv4_address": "10.42.250.49"
},
"node_pools": [
{
"ahv_config": {
"cpu": 1,
"disk_mib": 122880,
"memory_mib": 8192,
"network_uuid": "{{subnet_uuid}}",
"prism_element_cluster_uuid": "{{cluster_uuid}}"
},
"name": "dev_master_node_pool",
"node_os_version": "ntnx-0.6",
"num_instances": 1
}
]
},
"metadata": {
"api_version": "v1.0.0"
},
"storage_class_config": {
"default_storage_class": true,
"name": "default-storageclass",
"reclaim_policy": "Delete",
"volumes_config": {
"file_system": "ext4",
"password": "{{pe_password}}",
"prism_element_cluster_uuid": "{{cluster_uuid}}",
"storage_container": "{{container_name}}",
"username": "{{username}}"
}
},
"workers_config": {
"node_pools": [
{
"ahv_config": {
"cpu": 1,
"disk_mib": 122880,
"memory_mib": 8192,
"network_uuid": "{{subnet_uuid}}",
"prism_element_cluster_uuid": "{{cluster_uuid}}"
},
"name": "dev_worker_node_pool",
"node_os_version": "ntnx-0.6",
"num_instances": 2
}
]
},
"name": "multi01",
"version": "1.16.10-0"
}
因為我們使用的是創建單主機集群時使用的相同 API 端點，所以響應的格式與上一個請求的響應格式相同：cluster_uuid，task_uuid和cluster_name。
在我們的一個或多個集群現在正在運行或仍在部署的情況下，能夠查詢它們將有所幫助。
Karbon API 還公開了一個端點，用於獲取有關特定集群的信息。 這是一個 GET 請求，必須使用以下 URI：
https://[prism_central_ip_address]:9440/karbon/v1/k8s/clusters/[k8s_cluster_name]
在這一部分中，我們將使用多主群集的名稱– multi01。 將上面的 [k8s_cluster_name] 替換為我們的集群名稱將返回類似於以下所示的響應：
{
"etcd_config": {
"node_pools": []
},
"kubeapi_server_ipv4_address": "10.42.250.49",
"master_config": {
"deployment_type": "multi-master-active-passive",
"node_pools": []
},
"name": "multi01",
"status": "kDeploying",
"uuid": "90ac2d10-a83c-42d0-69d4-c0382531b247",
"version": "v1.16.10",
"worker_config": {
"node_pools": []
}
}
這裡顯示了很多有用的信息：
我們的有效負載中指定的 Kubernetes API 服務器 IP 地址，即 10.42.250.49
部署類型，即多主-主動-被動
對於本部分，最重要的是狀態為 kDeploying-該集群當前正在部署中，尚未準備好使用
部署完成後，兩個都將在 Karbon UI 中顯示為“健康”，就像使用 UI 本身創建它們一樣。 在下面，我們可以看到本文中的兩個演示集群都已部署並且運行良好，還有一個同事擁有的另一個集群。
已部署單主群集和多主群集，並且運行狀況良好
使用Karbon API 創建的 K8s 群集與使用 Karbon UI 創建的 K8s 群集完全沒有區別。 因此，我們仍然可以下載由 Karbon 生成的“ kubeconfig”文件。 該文件用於對已部署的 K8s 集群運行 kubectl 命令。 請參閱《Nutanix Karbon指南》中的“下載Kubeconfig”以獲取官方文檔。
不過，對於我們今天所做的事情，還可以使用 Karbon API 下載 kubeconfig 文件。 GET 請求 URI 如下：
https://[prism_central_ip_address]:9440/karbon/v1/k8s/clusters/[cluster_name]/kubeconfig
將此請求發送到 Prism Central 並用有效的集群名稱替換 [cluster_name] 將返回包含 kubeconfig 的 JSON 響應。 下面顯示了一個示例–刪除了證書頒發機構數據和令牌，使該示例更易於閱讀：
{
"kube_config": "# -*- mode: yaml; -*-\n# vim: syntax=yaml\n#\napiVersion: v1\nkind: Config\nclusters:\n- name: single01\n cluster:\n server: https://10.42.250.85:443\n certificate-authority-data: CERT_AUTHORITY_DATA_HERE\nusers:\n- name: default-user-single01\n user:\n token: TOKEN_HERE\ncontexts:\n- context:\n cluster: single01\n user: default-user-single01\n name: single01-context\ncurrent-context: single01-context\n\n"
}
本文詳細介紹了 JSON 有效負載和 Karbon API 端點，這些端點可用於以編程方式部署 K8s 集群，並獲取有關已經由 Karbon 管理的集群的信息。 儘管就 API 概念而言，這不是一個困難的過程，但有效載荷本身可能首先需要花費時間才能弄清楚。
希望以上示例演示瞭如何將 Karbon API 和 K8s 部署自動化集成到您自己的工作流程中。
感謝您的閱讀，祝您有美好的一天！
iThome鐵人賽
看影片追技術